Kotlin progresse encore pour atteindre 1,18% de part de marché.
J'ai mis à jour ce post afin de montrer l'évolution. 14 places en 1 an c'est beaucoup. Je pense que Kotlin est en train de manger les parts de Java et le phénomène s'accélère.
Par contre qu'arrivera-t-il à la JVM lorsque Java ne sera plus utilisé et que Kotlin l'aura remplacé ?
Pour moi, la JVM devrait se transformer en moteur d'exécution et plusieurs langages tourneront dessus.
D'ailleurs c'est le projet d'Oracle avec GraalVM qui est déjà polyglotte et marche très bien.
Je travaille en ce moment sur deux projets, un en Java/Kotlin pour des clients, un second en Rust pour des besoins internes, et j'ai réalisé la chose suivante :
- En Java/Kotlin, le langage est fait pour vous aider mais vous allez vous battre contre les frameworks.
- En Rust, les frameworks sont faits pour vous aider mais vous allez vous battre contre le langage.
C'est incroyable à quel point le borrow checker vous pousse à écrire du code procédurale et mécaniquement intestable. Dès l'instant où l'on souhaite passer par des traits tout devient ultra compliqué. Dernièrement je me suis faite avoir en utilisant des Rc
et des RcCell
sur un code qui allait devenir multi-thread #Horreur
Pour moi, casser le couplage entre deux composants via une interface/trait est IN-DIS-PEN-SABLE mais Rust pousse à définir des structures comme contrat d'interfaçage principal entre deux pans de code.
Forcément, le langage se transforme en enfer dès l'instant où l'on souhaite dépendre d'un trait et non d'une structure (c'est pourtant le 'I' de SOLID, dépendre des Interfaces mais pas des Implémentations).
En même temps je l'avais déjà dit par le passé, le paradigme fonctionnel pur est un cancer métastasé car l'expressivité de la syntaxe donne le sentiment que des tests ne sont pas nécessaires or c'est toujours faux.
Et j'ai suffisamment souffert de Java dans ma vie pour haïr le fait de devoir mocker/instancier/déclarer quarante-douze-mille trucs avant de pouvoir tester une simple fonction.
Bref, deux ans sur Rust à temps partiel et je me vois retourner dans le RustBook tous les 4 mois pour y chercher un truc #Pénible alors qu'en Kotlin ça ne m'arrive jamais.
Un article qui montre comment invoquer du JS depuis du code Kotlin qui sera transpilé en JS ensuite.
Je cherche à supprimer TypeScript du code de mes SPA pour n'avoir que du Kotlin côté back, du Kotlin transpilé/compilé vers du JS ou vers WASM côté front et du DSL en Kotlin via Ktorm pour le SQL.
Bref un langage pour les contrôler tous.
@Kalvn pour exécuter du JS sur Node quand tu veux avoir un maximum de contrôles appliqués par le compilateur tu peux aussi tout coder en Kotlin et transpiler tes sources en JS. Tu as un plugin Gradle et un plugin Maven qui gèrent ça pour toi.
On a du mal à se rendre compte à quel point Kotiln change la vie avant de l'avoir adopté. Je pense que le gain du passage de Java/C#/TS vers Kotlin est même plus important que le gain du passage de C/C++/ASM vers Rust, c'est dire !
Et avec le REPL des JRE 17+, on peut écrire des scripts en Kotlin (au sens Bash du terme), et ça c'est trop cool ! <3
L'évolution de la demande de développeurs Kotlin est en plein boom en France 😁 :
Rust ne suit pas encore mais c'est un résultat attendu puisque l'emploi est pour l'instant situé en Chine, en Corée et aux USA et l'étude se focalise sur la France. Au fil des mois, il devrait phagocyter tout doucement ses parts à C et surtout C++ 🤩 :
La bonne surprise c'est de voir que Kotlin se positionne très bien sur la grille des salaires bruts 🤑 :
Pour l'instant j'ai eu le nez creux avec Kotlin, il faut dire que le compilateur fait des choses époustouflantes, notament la preuve d'absence de de référencement de pointeurs (NullPointer) lors de la compilation, et que son API est merveilleuse comparée à Java (même si elle s'appuie dessus).
Il en va de même pour Rust, qui apporte tellement de choses qui manquent à C et C++, notamment la preuve d'absence de fuites memoire et de race-conditions dès la compilation ou encore un gestionnaire de paquets digne de ce nom.
Bref, attendons encore un peu avant de crier victoire mais pour l'instant, tout se profile comme il le faut pour moi et cela valait bien de s'investir autant 🥳.
Une introduction à ce qu'il est possible de mesurer à l'aide de l'utilitaire jcmd
embarqué dans les JDK.
Tout est dans le titre. Je suis en train de comparer plusieurs choses actuellement :
-
Le surcoût que représente la JRE 17 sur une application Kotlin.
-
Le gain qu'apporte une JRE 17 custom produite à l'aide de l'utilitaire JLink.
-
Les performances de (1) et (2) face à la même application codée en Rust, en termes de consommation mémoire et d'opérations par seconde.
-
Les nouvelles options que la JRE prends en paramètre et leurs effets sur le CPU, la mémoire et le débit.
Le tuning de JRE a toujours été compliqué, mais pour obtenir une JRE de 30 Mo optimisée comme il faut, il y a encore plus de choses à connaître et comprendre qu'avant. Damned !
Alors la situation est un poil plus compliquée que ce qui est dit.
Sur les vieilles versions de Java, Oracle fait effectivement la chasse aux licences. Mais il s'agit d'un modèle privateur donc normal.
Sur les versions 8 à 19 de Java, le modèle est basé sur trois composantes. Une JVM (machine virtuelle Java) avec les dernières features, une JVM avec les derniers correctifs de stabilité ou de sécurité, une JVM gratuite.
Quelle est l'astuce ? Simple, on ne peut pas avoir ces trois composantes simultanément.
C'est-à-dire que soit on veut avoir les dernières features et être stable/securisé et alors on paie.
Soit on ne paie pas mais dans ce cas on a :
- Soit les dernières features sur une JVM instable/non-sécurisée
- Soit on a une JVM avec 3 ans de retard sur les features mais qui est gratuite et stable/sécurisée.
Enfin, rappellons que Java est libre (GPLv2) et que les projets Eclipse Temurin, Apache et OpenJDK ont fusionné pour donner naissance à une JVM 100% libre Adoptium. Donc bye bye Oracle.
Remarque : si vous codez en Kotlin, puisque le compilateur peut cibler la version de la JVM que vous utilisez et vous fournir les dernières features sans que la JVM ne soit a jour, alors autant partir sur la dernière LTS gratuite de Java et être tranquille côté sécurité / stabilité.
Sinon Kotlin se compile très bien en WASM et en natif aussi <3
L'utilitaire JavaDoc ne fonctionne pas avec du code Kotlin (normal me direz-vous). Heureusement, Jetbrains fourni Dokka sous la forme de plugin Maven et Gradle permettant de faire la même chose.
Les annotations et syntaxes Dokka diffèrent un peu de la JavaDoc, voici un résumé :
@param Identique à JavaDoc
@property Pour documenter un attribut
@constructor Pour documenter un constructeur primaire
@return Identique à JavaDoc
Pour faire un lien vers une _classe/method/autre_ simplement écrire ceci
/** Je veux faire un lien vers [MaClass] **/
et Dokka fera le job
Attention, Java 6 n'étant plus supportée les dépendances kotlin-stdlib-jdk7 et kotlin-stdlib-jdk8 n'existent plus (puisque c'est Java 8 la version minimale requise pour Kotlin à présent).
Il faut donc les remplacer par kotlin-stdlib. Une migration simple qui va poser de nombreux problèmes à certains, sans aucun doute.
Je cite :
« À mesure qu'Android passe de C/C++ à Java/Kotlin/Rust, nous nous attendons à ce que le nombre de vulnérabilités liées à la sécurité de la mémoire continue de diminuer. Vivement un avenir où les bogues de corruption de la mémoire sur Android seront rares », a conclu Google.
Rust et Kotlin sont deux superbes langages (avec une petite préférence pour Kotlin). J'ai pourtant quelques reproches à faire à l'un et à l'autre mais quand je vois que le marché avance vers eux à grands pas, autant vous dire que j'en suis toute chose <3
Que du beau sous le soleil.
En un exemple court et simple :
package com.memorynotfound;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
public class GetUpTime {
public static void main(String... args) throws InterruptedException {
RuntimeMXBean rb = ManagementFactory.getRuntimeMXBean();
System.out.println("Up time: " + rb.getUptime() + " ms");
}
}
Edit
En complément il y a ce projet sur lequel jcefmaven est basé.
Problème
- J'ai besoin de développer un client lourd.
- Je préfère mourir que de me remettre à Swing ou d'utiliser JFX (dont la réputation d'API instable avait fait le tour du web il y a quelques années).
Solution
Cette dépendance Maven qui intègre un moteur de rendu WebKit :
<dependency>
<groupId>me.friwi</groupId>
<artifactId>jcefmaven</artifactId>
<version>105.3.36</version>
</dependency>
Avec le tuto pour Java
//Create a new CefAppBuilder instance
CefAppBuilder builder = new CefAppBuilder();
//Configure the builder instance
builder.setInstallDir(new File("jcef-bundle")); //Default
builder.setProgressHandler(new ConsoleProgressHandler()); //Default
builder.addJcefArgs("--disable-gpu"); //Just an example
builder.getCefSettings().windowless_rendering_enabled = true; //Default - select OSR mode
//Set an app handler. Do not use CefApp.addAppHandler(...), it will break your code on MacOSX!
builder.setAppHandler(new MavenCefAppHandlerAdapter(){...});
//Build a CefApp instance using the configuration above
CefApp app = builder.build();
Ceci se fait en deux étapes :
1) Déclarer la property dans le plugin Surefire comme suit
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>LAST_SUREFIRE_VERSION</version>
<configuration>
<systemProperties>
<property>
<name>name-the-property-will-have-in-test</name>
<value>${my-property}</value>
</property>
</systemProperties>
</configuration>
</plugin>
2) La récupérer en tant que propriété système dans les TU
val property = System.getProperty("name-the-property-will-have-in-test")
Kotiln, Rust et Python progressent et de plus en plus de développeurs les adoptent (et c'est très bien).
J'ai été une grande utilisatrice de Python il y a un peu plus d'une quinzaine d'années lorsque je travaillais en labo sur du Data-Mining (l'ancêtre du Machine Learning). J'avais laissé de côté Python pour trois raisons à l'époque :
- Les problèmes de performance.
- Les problèmes d'outillage autour du build.
- Le fait que les programmes écrits en Python, pour être rapides, doivent utiliser des libs écrites en C, et donc avec un code orienté procédure.
Aujourd'hui, si je devais produire un système temps-réel et très peu énergivore, je partirais sur Rust.
Dans tous les autres cas de figure, je prendrais Kotlin sur OpenJDK ou Kotlin native (via le compilateur Kotlin-native ou GraalVM).
Par contre Python n'est plus du tout dans ma liste car pour moi à présent, si l'exécution d'un langage n'est pas prouvée à la compilation, c'est un stop immédiat. La majorité des développeurs n'écrivant pas de tests et maîtrisant mal le code (en tout cas en industrie) c'est indispensable.
Kotlin 1.7 se profile à l'horizon. Je vais rester sur Koltin 1.6 cette année, mais si les évolutions sur Kotlin-JS et Kotlin-Native débarquent, je vais vite changer d'avis :P
Ahhh Java... Je me souviens de mon tout premier code en Java. J'étais encore au lycée, je voulais apprendre à faire des sites web pour notre club d'anglais et j'avais entendu parlé de JavaScript. Alors j'ai demandé un bouquin à mes parents mais vu le prix des livres à l'époque j'avais fait une croix dessus... Puis à Noël...
J'ai reçu un libre qui s'appelait Total Java ! Et mes parents tout fiers à l'époque : "Le libraire nous a dit que tu pourrais faire des sites avec ça"... Oui avec des Applets Maman #Facepalm.
En réalité, j'ai très vite adoré Java et puis j'ai appris à le détester en migrant vers Kotlin. Le langage en lui-même n'est trop pas mal :
- Il gère la programmation par structures.
- Il gère la programmation orientée objets.
- Il gère la programmation fonctionnelle.
- Il gère la programmation par aspects.
- Il gère la programmation asynchrone.
- Il gère la programmation concurrentielle.
- Il gère programmation réactive.
- Il gère la programmation événementielle.
A présent je me rends compte de la lourdeur de sa syntaxe, que sa capacité à gérer autant de paradigmes différents font de lui un langage dont la syntaxe devient au final incohérente, que la rétro-compatibilité ascendante garantie n'a jamais permis à Java de trier le bon grain de l'ivraie pour ne se focaliser que sur le nouveau ; rétro-compatibilité depuis 1995 quand même !
@Warrior Du Dimanche si tu as des questions en Java demande, je tâcherai d'y répondre :-*. Mais quitte à bosser sur JVM, je te recommande Kotlin, bien plus élégant, bien plus expressif, bien mieux !
Excellente idée ! Merci à @Philou pour le lien.
Retour d'expérience d'une équipe d'Amazon Prime sur l'utilisation de Kotlin à la place de Java.
Overall : 75% de devs satisfaits de la transition.
Excellent, je cherchais un moteur Kotlin 2D sympa pour un kata un peu gros. C'est top !
Merci @Riduidel